15.1: Publish!

Contents:

In previous practicals you learned how to build and test your app, and now it's time to learn how publish it. So, what do you have to do to publish your app? This chapter covers the the high-level steps for publishing your Android app to the Google Play store, and it introduces the Google Play developer console, where you can upload your app to Google Play. It does not teach you everything there is to know about the Google Play developer console. We hope, though, that after you read this chapter you will be excited to upload your app and investigate all the different features of the console.

This chapter has two main sections:

  • Prepare your app for release discusses the tasks you need to do to make sure your app is really ready to publish.
  • Publish! discusses alpha and beta testing, and how to use the Google Play developer console to publish your app.

Prepare your app for release

The main goal when preparing your app for release is to make sure it is really ready. Android users expect high-quality apps that look great and work well. There will always be more features that you want to add to your app, or more features that your users ask for. There's a big difference, however, between a great app that could be made even better versus an app that breaks often, provides an incomplete experience, has navigation paths that go nowhere, or does not have a way to get to the important parts of the app.

Think about your own favorite apps. What do you like about them?

Think about apps that you have uninstalled or hardly ever use. What didn't you like about them? Think about apps that you were excited to get but then were disappointed when you started using them. What caused that disappointment for you?

The high level tasks for publishing your app to the Google Play store are:

  1. Prepare the app for release.
  2. Generate the signed APK.
  3. Upload the APK to the Google Play developer console.
  4. Run alpha and beta tests.
  5. Publish to the world!

This chapter takes a high-level look at each of these tasks.

What is an APK?

An APK is a zip file that contains everything your app needs to run on a user's device. It always has the .apk extension. You need an APK to publish your app in the Google Play store.

You can use Android Studio to create the APK for your app. Before you generate the APK for your app, you need to do everything you can to make your app successful, including:

  • Test your app thoroughly.
  • Make sure your app has the correct filters.
  • Add an icon.
  • Choose an Application ID.
  • Specify API levels targets.
  • Clean up your app.

When your app is completely ready, then you can generate a signed APK to upload to the Google Play store.

Take a look at the launch checklist in the Android developer documentation.

Test your app thoroughly

As you develop your app, test it on your own Android device and in Android Studio's emulator. Make sure you test the app for different screen sizes and orientations. Also check that the app works properly on older devices.

Share your app with your developer friends. Make a zip file and send it to other developers. Then they can load your app into Android Studio and run it.

You know how your app is supposed to work, after all; you designed and built it. You know the "right way" to use your app. However, users have a really creative way of trying to use apps that you never would have believed, let alone considered. They might try to use your app or its features in ways you had not thought of, or might test it in ways you had not tested it. Encourage your testers to try out your app in different ways, to try to achieve different goals, and to take different paths navigating through the activities. This will help catch errors, inconsistencies, or functionality failures that you were not able to find, because you are too familiar with how the app is supposed to work.

Make sure you run formal tests on your app, including unit and Espresso tests. These tests should cover both the core features of your app, and the main integration points where your app calls out to another API or retrieves data from the web. These are points that are critical to your app, and they are the areas of code likely to break.

Use Firebase Test Lab to run your app on a range of real devices in Google's data centers. This way you can verify both the functionality and the compatibility of your app across many different kinds and versions of devices before to releasing your app to a broader audience.

Read about Firebase Test Lab for Android at firebase.google.com/docs/test-lab/.

Make sure your app has the right filters

When a user searches or browses for apps in the Google Play store, the results include only apps that are compatible with the user's device. For example, if a person uses a phone that has a small screen, Google Play's search results do not include apps that require a large TV-sized screen.

Make sure your app specifies the appropriate requirements to ensure that it reaches the right audience. For example, if your app requires biometric hardware for reading fingerprints, then add the requirement in the Android manifest.

<uses-feature android:name="android.hardware.fingerprint"/>

However, specifying that your app needs a fingerprint reader limits the audience for your app to people who have devices with a fingerprint reader. You should think carefully before adding restrictions to the manifest that might limit who can see and download your app.

If your app really does need a particular attribute to be present on the user's device, then make sure to include that restriction in the manifest, to ensure that everyone who can find and download your app can actually run it. People are very likely to give your app a bad review if they install it only to find that it does not run on their device.

Hardware filters

You can specify that your app uses hardware features, such as:

  • light sensor
    <uses-feature android:name="android.hardware.sensor.light" />
  • gamepad
    <uses-feature android:name="android.hardware.gamepad" />
  • step counter
    <uses-feature android:name="android.hardware.sensor.stepcounter" />
  • and many more

See the full list at developer.android.com/guide/topics/manifest/uses-feature-element.html.

Software filters

You can specify that your app requires the device to have software features such as:

  • a particular shared library is installed. For example:
    <uses-library android:name="com.google.android.maps"/>
  • uses a minimum Android API level. For example:
    <uses-sdk android:minSdkVersion="19">

Countries

In the process of uploading your app to Google Play, you can select the countries where your app will be available. If you specify this, then only users in those countries will be able to find and download your app.

Add a launcher icon to your app

A launcher icon is a graphic that represents your application. The launcher icon for your app appears in the Google Play store listing. When users search the Google Play store, the icon for your app appears in the search results.

When a user has installed the app, the launcher icon appears on the device in various places including:

  • On the home screen
  • In Manage Applications
  • In My Downloads Launcher icons on the home screen

Read the Launcher Icons design guide for advice on designing your launcher app to encourage users to use your app.

Add an Application ID

The Application ID uniquely identifies an application. Make sure your app has an Application ID that will always be unique from all other applications that a user might install on their device.

When you create a project for an Android application, Android Studio automatically gives your project an Application ID. The value is initially the same as the package for the app. The Application ID is defined in the build.gradle file. For example:

defaultConfig {
   applicationId "com.example.android.materialme"
   minSdkVersion 15
   targetSdkVersion 24
   versionCode 1
   versionName "1.0"
}

You can change your app's Application ID. It does not have to be the same as your app's package name. At times as you worked through the practicals in this course, you created a copy of an Android Studio project. After copying the project, you changed the Application ID to make sure that it was unique when you installed the app on your device.

When you are getting ready to publish your app, review the Application ID. The Application ID defines your application's identity. If you change it, then the app becomes a different application and users of the previous app will not be able to update to the new app.

Specify API Level targets and version number

When you create a project for an Android app in Android Studio, you select the minimum and target API levels for your app.

  • minSdkVersion — minimum version of the Android platform on which the app will run.
  • targetSdkVersion — API level on which the app is designed to run.

You can set these values in the Android manifest file, and also in the app-level build.gradle file.

Note: The value in build.gradle overrides the value in the manifest file. To prevent confusion, we recommend you put the values in build.gradle, and remove them from the manifest file,. Setting these attributes in build.gradle also allows you to specify different values for different versions of your app.

When you get your app ready for release, review API level targets and version number values and make sure they are correct. People will not be able to find your app in the Google Play store if they are using devices whose SdkVersion is below the value specified in your app.

Here's an example of setting these attribute values in build.gradle:

android {
  ...
  defaultConfig {
    ...
    minSdkVersion 14
    targetSdkVersion 24
}

Note: The values of minSdkVersion and targetSdkVersion are the level of the API, not the version number of the Android OS.

Codename

Version

Release Date

API Level

Honeycomb

undefined

3.0 - 3.2.6

Feb 2011

11 - 13

Ice Cream Sandwich

undefined

4.0 - 4.0.4

Oct 2011

14 - 15

Jelly Bean

undefined

4.1 - 4.3.1

July 2012

16 - 18

KitKat

undefined

4.4 - 4.4.4

Oct 2013

19 - 20

Lollipop

undefined

5.0 - 5.1.1

Nov 2014

21 - 22

Marshmallow

undefined

6.0 - 6.0.1

Oct 2015

23

Nougat

undefined

7.0

Sept 2016

24

Version number

You need to specify a version number for your app. As you improve your app to add new features, you will need to update the version number each time you release a new version to the Google Play store. Read more in the Android Version guide.

Product Flavors

You can generate different "product flavors" for your app. A product flavor is a customized version of the application build. For example, you could have a demo version and a production version. Here's an example of how to define product flavors in build.gradle:

android {
  ...
  productFlavors {
    demo {
      applicationId "com.example.myapp.demo"
      versionName "1.0-demo"
    }
    full {
      applicationId "com.example.myapp.full"
      versionName "1.0-full"
    }
    }
}

Read more about product flavors in the Build Configuration developer guide.

Reduce your app's size

The size of your APK affects:

  • how fast your app loads
  • how much memory it uses
  • how much power it consumes

The bigger the size of your app's APK, the more likely it is that some users will not download it because of size limitations on their device or connectivity limitations. Users who have pay-by-the-byte plans will be particularly concerned about how long an app takes to download. If your app takes up too much space, users will be more likely to uninstall it when they need space for other apps or files.

Take a look at the apps on your own Android phone now. Which apps take up the most space? If you ran out of space on your Android phone, which of the apps that you downloaded would you uninstall? Size of apps

There's no magic to minimizing the size of your app's APK, most of what you need to do is common sense. For example:

  • Clean up your project to remove unused resources
  • Re-use resources
  • Minimize resource use from libraries
  • Reduce native and Java code
  • Reduce space needs for images

Clean up your project folders

The first step in making your app as small as possible is to clean up your project folders so that when you create the APK, Android Studio includes only the files that your app needs.

An APK file consists of a ZIP archive that contains all the files that comprise your app. These files include Java class files, resource files, and a file containing compiled resources.

The high level project folders in your project are:

  • src: This folder contains the source files for your app. Remove any Java files that are not used. Make sure the folder does not contain any .jar files.
  • lib: This folder contains third-party or private library files, including prebuilt shared and static libraries (such as .so files). Make sure you remove any unused library files.
  • jni: This folder contains native source files associated with the Android Native Developer Kit, such as .c, .cpp, .h, and .mk files.
  • res: The res sub folders contain the resources such as layouts, colors, strings, styles that your app uses.
Note: While you are developing your app, it can be easy to create additional resources that your app ends up not using, so be sure to check for and remove unused resources.

Disable logging and debugging and check production URLs

While you are developing your app, you are no doubt testing it carefully, perhaps adding unit tests, showing toasts, and writing logging statements. When you prepare your app for release, you need to remove all the extra code.

To disable logging and debugging:

  • Remove logging statements and calls to show toasts
  • Remove all Debug tracing calls from your source code files such as startMethodTracing() and stopMethodTracing().
  • Disable debugging in the Android manifest by either:
  • Removing android:debuggable attribute from tag
  • Or setting android:debuggable attribute to false
  • Remove unused tests

Also, make sure that if your application accesses remote servers or services, it uses the production URL or path for the server or service and not a test URL or path. Likewise, many companies with public APIs have test permissions and production level permissions. Make sure that your security or passwords for accessing these servers are production level as well.

Reduce the size of your app's images

Reducing the size of the images in your app can go a long way to reducing the size of the APK file.

  • First, make sure your app does not contain any image resources it does not use.
  • For each static image your app uses, you need to create separate versions of that image for all screen sizes that your app might run on. However, in some cases, you can use Drawable objects, VectorDrawables, and 9-patch files instead.
  • If your app uses static images, be sure to crunch PNG files, and compress both PNG and JPEG files to minimize their size. You can use Google to search for crunching, crushing, and compressing tools for images.
  • Consider using WebP format for images. Android supports WebP from Android 4.0+.

Read more about how to reduce the size of your app in the Reduce APK size guide.

Note: Drawable objects are defined in XML. Android draws them when the app needs to display them, which means your app does not need to store images for them. However, because Android generates them as needed, it can take longer for the images to appear on screen, so it's best to use Drawable objects for smaller images such as icons and logos. Drawable objects do not support the same complexity and detail that you can get with bitmaps.

In Android 5.0 (API Level 21) and above, you can define vector drawables, which are images that are defined by a path. Vector drawables scale without losing definition. Most vector drawables use SVG files, which are plain text files, or compressed binary files that include two-dimensional coordinates for how the image is drawn on the screen. Because SVG files are text, they use less space than most other image files. Also, you only need one file for a vector image instead of a file for each screen density.

Consider the use case for your images, and use Drawable objects and 9-patch files wherever it makes sense. See the Drawable, Styles and Themes lesson in this course for more information.

Generate the signed APK for release

When your app is ready to upload to Google Play, you must generate and sign the APK for your app. Android Studio has tools for generating your APK and signing it with a digital certificate.

When Android Studio signs the app, it creates a public certificate and a private key. It attaches the public certificate to the APK. You must securely store the private key in a keystore

The public-key certificate serves as as a "fingerprint" that uniquely associates the APK to you and your corresponding private key. This helps Android ensure that any future updates to your APK are authentic and come from you, the original author.

For information about digital certificates, storing your private key, and generating the digitally-signed APK, see the guide Sign Your App.

Publish your app!

When you've tested your app, cleaned it up, reduced its size, and generated the APK, you are ready to publish it to Google Play.

After you upload your app to Google Play, you can run alpha and beta tests before releasing it to the public. Running alpha and beta tests lets you share your app with real users, and get feedback from them. This feedback does not appear as reviews in Google Play.

Run alpha tests while you are developing your app. Use alpha tests for early experimental versions of your app that might contain incomplete or unstable functionality. Running alpha tests is also a good way to share your app with friends and family.

Run beta tests with limited number of real users, to do final testing before your app goes public.

Once your app is public, users can give reviews. So, make sure you test it thoroughly before putting it out on Google Play for anyone to download.

For more information on alpha and beta tests see:

Create an account in the Google Play Developer Console

Whether you want to run alpha and beta tests, or publish your app to the public on Google Play, you need to upload your APK in the Google Play developer console.

Go to the console at play.google.com/apps/publish/.

To begin, get a Google Play developer account. You will need to pay for the account. The high-level steps are:

  1. Go to play.google.com/apps/publish/
  2. Accept the agreement.
  3. Pay the registration fee.
  4. Enter your details, such as your name, address, website, phone and email preferences.

When you have set up your account, you can upload your APK. In the Google Play Developer console interface, choose:

  • Production
  • Beta Testing
  • Alpha Testing

Then you can browse for the APK to upload, or drag and drop it to the console. Google Play developer console

You need to satisfy the following requirements before you can publish your app to the public:

  • add a high-res icon
  • add a feature graphic (in case your app is selected as a Featured App in Google Play)
  • add 2 non-Android TV screenshots
  • select a category
  • select a content rating
  • target at least one country
  • enter a privacy policy URL
  • make your app free or set a price for it
  • declare if your app contains ads
  • add a required content rating

This list might seem long, but the Google Play developer console helps you figure out if your app is ready to launch. Click the "Why can't I publish?" link to find out what else you need to do to publish your app.

Run pre-launch reports

After you upload your APK, you can run pre-launch reports to identify crashes, display issues and security issues. During the pre-launch check, test devices automatically launch and crawl your app for several minutes.

The crawl performs basic actions every few seconds on your app, such as typing, tapping, and swiping. The pre-launch tests use Firebase Cloud Test Lab.

For more information on pre-launch supports, see the Google Play Help center article Use pre-launch reports to identify issues.

Review criteria for publishing

Your app must comply with Google Play policies, which ensure that all apps on Google Play provide a safe experience for everyone.

There are policies governing

  • Restricted content
  • Intellectual property, deception and spam
  • Privacy and security
  • Monetization and ads
  • Store listing and promotion
  • Families

Learn more at play.google.com/about/developer-content-policy/

Restricted content

Google Play does not allow apps that are sexually-explicit, hateful, racist, encourage bullying or violence, or facilitate gambling.

https://play.google.com/about/restricted-content/

Intellectual property, deception and spam

Google Play does not allow apps that are not honest. In other words, they pretend to be other apps or pretend to come from other companies or impersonate other brands. Google Play does not allow apps that attempt to deceive users. Google Play does not allow apps that spam users such as apps that send users unsolicited messages. Google Play does not allow apps that are duplicative or of low-quality.

https://play.google.com/about/ip-deception-spam/

Privacy and security

Google Play requires that your app treats users' data safely and keeps private user information secret. If your app accesses or transmits private data, it must publish a statement about how it uses users' data.

Google Play does not allow apps that damage or subversively access the user's device, other apps, servers, networks, or anything that it should not. Basically, your app should not interfere with anything else, or cause any damage to anything, or try to access anything that it does not have authorization to access.

Google Play does not allow apps that steal data, secretly monitor or harm users, or are otherwise malicious.

https://play.google.com/about/privacy-security/

Monetization and Ads

Google Play has rules regarding accepting payment for in-store and in-app purchases.

Google Play does not allow apps that contain deceptive or disruptive ads.

https://play.google.com/about/monetization-ads/

Store Listing and Promotion

Publishers must not attempt to promote their own apps unfairly. For example, you are not allowed to get 100,000 of your closest friends to give your app a 5 star rating so that it appears with very favorable reviews. Your app's icon, title, description and screenshot must all fairly represent your app, and not make any exaggerated or misleading claims.

In other words, don't cheat to get a better Google Play rating or placement.

https://play.google.com/about/storelisting-promotional/

Submit your app for publishing

When you upload your app for production, Google checks your app. Google runs both automatic and manual checking on your app.

If your app is rejected, fix the problem and try again!

Final summary

You have reached the end of this course. We hope you have enjoyed the journey and that you feel ready to go build your own Android apps. We look forward to seeing your apps in the Google Play store!

Learn more

Preparing your app

Google Play Developer Console

Alpha and Beta testing

results matching ""

    No results matching ""